Our DPL has spoken to The Register about the developer status proposal and how we’ll handle it after the release of Lenny.
Too bad he hasn’t told us anything about it on our mailing-lists yet. Maybe The Register could create a Debian category so we can more easily look for what our DPL says?
(If anyone asks, I’m a Reg reader myself)
While I don’t really have a strong opinion on the suggestions in Ganneff’s announcement in d-d-a, as I haven’t had time to think deeply about the consequences that they would have, but which I foresee to be very important (they could have strong implications in the Debian Project), and making use of my freedom of speech, I must say that I agree with Joey and Julien. I don’t like how the whole proposal has been done, and I also fear the accumulation of power that slowly seems to be going along in Debian. I believe that spread power usually is much better and healthier than the opposite, and if it’s true that decisions are being increasingly taken in cabals, we’re going in the wrong direction. About Julien’s post on people being too coward to say what they think, a long time ago I posted about NM process saying that “If you want to finish university, you should take care about getting on with the teachers. The result are submissive citizens that won t face authority even if they know they re right, in order to avoid problems“, and “What should be taken care about is that the NM process don t filter Over the past four years (since the infamous Vancouver meeting, roughly), it seems it has slowly become an acceptable practice in this project to come up with backroom decisions instead of coming up with ideas and proposals and building a consensus before moving forward.
A number of projects and changes have been brought forward this way since then. No need to make a list, I think everybody remembers the flamewars pretty well.
Fact is that Vancouver and dunc-tank (only to name those two) have changed the Project in some ways. People resigned, others changed their level of involvement, but more than anything else, there’s been a split in the Developer body. Something broke at some point, and the spirit just isn’t there anymore.
So, we’ll never recover to a state comparable to what Debian was before Vancouver.
When you thought things were bad enough already, they just got worse. We now have people coming up with decisions all by themselves. No asking anyone about it, even in backroom meetings, or only to fake it and ignore their opinions on the matter.
It looks bad, and it is. Talk about communication problems. Talk about power-hungry people.
But let’s talk about cowards, too. The cowards that are bitching about what’s happening but won’t raise their voices on the lists because they’re afraid of looking bad if they disagree with the “big boys”.
We are a free software project. Free as in freedom, free as in speech. If you’re not making use of this freedom, you’re just going to lose it; just like in the “real world”. Actually, you’ve lost some of this freedom already.
If you’re not voicing your opinion, why do you have one in the first place?
Digi released a new beta release of the dgap drivers a couple of days ago, notably fixing the build issue (TTY flip buffer) with newer kernels.
They now ship two versions of the driver, one suitable for 2.4 and 2.6 kernels up to and including 2.6.26, and one for kernels 2.6.27+. The appropriate version will be picked up automatically when the module is built, of course.
APT source line, unchanged:
deb http://debian.technologeek.org/ etch non-free
The packages are still built for Etch; Sarge users should stay with 1.3.6 (unless running a newer kernel, but then a rebuild of the userspace tools is required).
Feedback at the usual address.
Answer to anybody asking about the Lenny release.
(semi-joke only fully understandable by French folks. Julien Blache used the same joke in the past)
My dear Genneff, "Valid-Until" is certainly a good idea and I have no doubt it's well implemented in our archive tools.
I'm less sure about this being implemented in apt, because of the loose resources of the APT maintenance "team" as of now.
And I'm damn sure that implementing that feature will add yet more work coordinating l10n. APT is currently fully translated to 18 languages and, of course, the warning message issued by APT when a user is directed to a faked security repository *has* to be translated for the user to really understand what's happening. It even has to be translated very carefully.
Contrary to popular belief, not all systems admins understand English easily. And we really want the important message that will be issued by APT in such case, to be understood and understood well.
So, good luck to /me dealing with a last minute l10n update that will
quite certainly happen, now.
I can't even use this in an attempt to get bug #500000, as #499897 is already reported against apt. Crap. I'm out of ideas for getting that bug report...
As a revenge, I propose that next time we all see Ganneff in a group, we all hug him to death for implementing that very good feature in our archive tools.
I’ve just taken over the maintenance of mt-daapd and gave the package and code the thorough cleanup it so badly needed.
I’ve fixed everything that was reported againt mt-daapd and a bit more. No miracles though, the code is still not great and there still hasn’t been an official upstream release in … years?
It works for me as well as it did before, so hopefully I’ve fixed bugs and did not introduce new ones in the process. Now that’s up to you, mt-daapd users, to tell me :-)
Go grab mt-daapd 0.9~r1696.dfsg-1 in experimental and enjoy.
Lazyweb-type post ahead :)
I am looking for the UGA (Universal Graphics Adapter) specification. It is part of EFI 1.10, but was developed by Microsoft, so it’s not documented in the Intel spec.
Instead, the Intel spec contains a Microsoft URL where the spec used to be available, but that URL doesn’t exist anymore and I can’t find the spec anywhere.
So, if anybody out there has a copy of that spec, I’d very much like to get it.
I am looking for the UGA IO Protocol spec, which may very well be the key to solving an annoying framebuffer issue I’m working on.
Thanks!
It’s been on the TODO list for ages now, and Soeren finally tackled it: compositing support for gpomme.
This is the only change in this release. Please report any issue with gpomme and compositing, as this code has only been tested on a limited number of configurations.
For people not running a compositing manager (like myself), don’t worry, gpomme works just as before.
As already announced by Julien Blache, I successfully passed my PhD defense today, and I am now a doctor.
During my PhD, I designed and implemented an optical simulator for the MUSE instrument, an integral field spectrograph which will be installed on one of the large European telescopes of the VLT.
Aur lien JARNO defended his PhD this morning, and I’m just back from attending his defense.
He did an incredible work designing and implementing a simulator for the MUSE instrument that will equip the VLT in 2012 (”first light”) and is being built now.
People working in the field are very impressed by the work he achieved, and I must add that it’s even more impressive when you know all he did in Debian and various other projects at the same time. Wow.
Congratulations Dr. JARNO!
As of 09:53am CEST today, I am officially available for hire starting mid-August, and looking for a job.
I’m going to enjoy some time off in the nice, sunny weather we’ve got here these days and I’ll have some time again to try and add proper support for the Intel Macs to d-i. Not that bad after all.
pommed v1.20 is out, with two minor fixes:
Joey,
I think your whole post only applies to HAL.
Fact is, DBus lets you know through a dedicated signal that you’ve been disconnected from the DBus server; at that point, you cleanup the connection and try to reconnect. Works for me.
Now, the fact that HAL (and/or libhal, it seems) provides no way of handling this situation cleanly is obviously a major bug.
I’m not a great fan of all the desktop crap that’s being promoted and hyped lately, but I am positive about DBus. DBus provides the mechanisms to handle a DBus restart properly, HAL (and pretty much everything else) doesn’t use them, blame HAL, not DBus, for this one.
As for the “DBus should never be restarted”… I have no idea why the DBus upstreams would think that, but that also wouldn’t be the first time distributions disagree with upstreams about what is good and what isn’t. The good news is, this is all free software and we can fix it without upstream’s blessing.
If somebody out there really believes that it is OK for applications to crash/exit when DBus is restarted, then I don’t have the words.
I won’t even mention the new behaviour of the DBus init script in Sid.
pommed v1.19 has landed, with improvements wrt CPU usage.
This is especially true for gpomme, which won’t cause 10 wakeups/sec anymore. PowerTop fans, rejoice! I plan to fix wmpomme too, but as I’m probably the sole user, this can wait.
pommed will also consume a bit less CPU, especially on machines without ambient light sensors.
The new code in pommed makes use of the timerfd API introduced in Linux 2.6.25, hence you’ll need to run a 2.6.25 kernel or later; pommed will not operate properly on earlier kernels.
You maintain an application that uses DBus? Better yet, you are upstream for an application that uses DBus?
Then, please:
GET OFF YOUR ASS AND HANDLE DBus SERVER DISCONNECTION/RECONNECTION INSTEAD OF CRASHING
kthxbye.
After nearly two years stuck with rEFIt 0.7 in Debian, I’ve uploaded rEFIt 0.11 to unstable today.
There’s been a bit of work done on the package, on rEFIt itself and on the tools that come with rEFIt. I’ve also added some (useful, I hope) documentation.
This version of rEFIt supports all Intel Macs to date.
rEFIt in Debian comes with gptsync, both as a Unix command-line tool and as an EFI application. It’s the only tool shipped in the package. The other tools available in the rEFIt binary distribution by upstream (the EFI Shell and utilities) come from the TianoCore project and aren’t available in Debian. See the README.Debian in rEFIt if you want the full story.
Also rEFIt in Debian lacks the machine shutdown feature for now; this feature is part of the EFI 1.10 spec which isn’t supported by gnu-efi yet, though I have also worked on updating gnu-efi for EFI 1.10 and sent this upstream. Filesystem drivers are also affected by this and, as such, are unavailable too.
If you’re interested in the gory details, see the changelog and patches.
I’ve just released pommed v1.18, which is mainly a maintenance release.
I’ve added some more USB IDs for Apple external keyboards and relaxed the event devices identification for internal keyboards.
pommed will now happily start on a machine fitted with a keyboard+trackpad assembly that normally isn’t found on this model. This can happen when the topcase of the machine is replaced with the wrong part. I expect this situation will happen more and more often as people buy parts from EBay or similar to repair their laptops.
Worst Debian day ever since the 2003 compromise. And that was a BAD one.I disagree. This is far, far worse than the 2003 compromise. The compromise was scary, but the key updates for users were straightforward and as far as we know, user security was never actually compromised. In contrast, every single user who uses Debian or Ubuntu for anything serious is now (Update: and has been for two years) vulnerable to attacks on their supposedly secure cryptography [0] unless they perform a labor-intensive and error-prone series of steps to regenerate all their cryptographic keys -- not to mention finding a secure way to distribute their public keys to everyone who needs them! [0]: Update: I should perhaps make it clear that I mean anyone who generated a key on such a system. But in a way this makes things worse: unless you're willing to regenerate every key in sight, you need to check each key manually, which means that there's a nontrivial chance that you'll overlook one and leave yourself vulnerable...
Because a lolcat is worth a thousand jokes, here are 3 of them.
Thanks to rominet for coming up with those :-)
Next.